Amazon Athenaでペタバイト級のデータレイクを捌ききるFINRA社の事例 #ANT308 #reinvent

AWS re:Invent 2020

#レポート

#Amazon Athena

#AWS

春田拓海 | Takumi

2020.12.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

どうも！DA部の春田です。

本記事は、AWS re:Invent 2020のセッション動画、「ANT308: How FINRA operates PB-scale analytics on data lakes with Amazon Athena」のレポート記事です。

English version is here.

個人的に長いこと業務でAthenaを使ってますが、ペタバイト級のデータをAthenaで扱っている事例は珍しく感じました。データを配置するS3側をしっかりチューニングしておけば、DWHとしても問題なく運用できるみたいです。

先日、様々なアップデートが詰め込まれたAthena engine 2.0が発表され、最近ついに東京リージョンでもGAとなりました。ビッグデータ分析基盤の選択肢に、コスパの高いAthenaも敵うようになってきましたね。

概要

FINRA社は、米国でビジネスを展開する全てのセキュリティ企業のための自主規制機関であり、自己資本や社債、セキュリティの未来や選択肢の取引を制御している。セキュリティやSLAはFINRAにとって重要であり、規制の要件を満たすために追求している。このセッションではFINRAがどのようにして、1500以上のアナリストとビジネスパートナーが、1日で数TBずつ増加し続けている金融取引データをクエリできるAmazon Athena上のアプリケーションを開発したかをご紹介していきます。Amazon S3ベースのデータレイクと、オープンソーステクノロジー、Amazon Athenaを使って、どのように大規模分析基盤を運用しているのかについてや、パフォーマンスや運用効率・コストを改善するためのテクニックについても解説しています。

スピーカー

Janak Agarwal
- AWS Speaker
Alain Menguy
- Systems Director - FINRA

How FINRA operates PB-scale analytics on data lakes with Amazon Athena - AWS re:Invent 2020

内容

Amazon Athenaの概要
FINRAとは？FINRAのミッションは？
アプリケーション要件
なぜAmazon Athenaにトライしたのか？
Amazon Athenaを既存のシステムにどう導入したか？
今後のAthenaに期待する改善点
将来の展望 - ユニバーサル・データアクセス

Amazon Athenaの概要

Amazon Athena
- S3ベースのデータレイクのための、サーバレスでオープンソース互換のクエリサービス
- Amazon S3のデータに直接クエリ
- インフラ、オペレーション、アプリケーションログの分析
- BIツールを使用して、インタラクティブに分析
- データサイエンティストのためのデータ探索も
- 分析機能をアプリケーションに埋め込むことができる

サーバレス：インフラの管理が不要
JDBC・ODBCで接続
シンプルなコンソールから即座にクエリ実行
スキャンしたデータ量に対してのみ課金
圧縮データに対してクエリすれば、30~90%のコスト削減が可能
Federated Queryを用いれば、RedshiftやRDSといったデータソースに対してもクエリ可能
Parquet、Avro、ORCに対応
データをat restとin transitで暗号化
AWS Private Linkを使用すれば、IGWが不要に

1年半で100以上の機能を追加
- Federated Query
- 機械学習インターフェイス
- Workgroupによるコストコントロール

FINRAとは？FINRAのミッションは？

ミッション
- セキュリティ市場を規制し、投資家を改ざんやインサイダー取引から守る
企業や為替取引からデータを収集している

ビジネス的なデータの流れ
- データプロバイダーが為替情報を保存し、SFTPやHTTPS経由でFINRAへ転送する
- FINRAは1日あたり10~20TBのデータを受信している
- 仕様や要件を満たしているか、ファイルのバリデーションを行う
- ファイルをデータカタログに登録する
- 1日あたり数千のETLジョブが実行され、分析用の前処理を行う
- アノマリーを検知しアラート出すための、自動検知モデルが実行される

データレイク・アーキテクチャ
- 全てのデータをAmazon S3に保存し、どの過去データにもアクセスできるようにする
- 自社製のOSSデータカタログ、HERDを開発
  - herd big data
- ストレージとコンピュートの分離
データを保護する
- at restで暗号化
  - Amazon S3上のデータに対してAmazon KMS SSEを使用
  - Amazon EMRで使用しているephemeralやAmazon EBSのボリュームは、LUKSで暗号化
- in transitで暗号化
  - HTTPS、SSL
- S3バージョニング
  - 更新や消去される前の古いバージョンのファイルも取っておく
- 他のリージョンやアカウントへバックアップ
  - 主要AWSリージョンやアカウント障害に備えて
  - Amazon S3 Glacierに保存し、コスト削減

技術スタック
- ECS, EC2: Webアプリケーション、SFTPレイヤ
- S3: 全データを保管
- HERD: 全データを登録するFINRA製のデータカタログ
- EMR: HiveやSparkを使ったETL処理、HBaseやPrestoのリアルタイム分析
- Redshift, Athena: データ分析
- Databricks, SageMaker: RやPython、Scalaを用いた機械学習ワークロード

アプリケーション要件

CATFOLA Viewer
- 注文ライフサイクル組み立てツール（The order lifecycle assembly tool）
- CAT Lifecycle IDか数種のキーで使用可能
- ライフサイクルに関与した全てのイベントを即座に動的に返す
1500~2000億レコードを抽出（日次）
推定ボリューム10~20TB（日次）
保持期間6年
- 最大300兆のレコード
- 最大25PBのAmazon S3ストレージ
HERD（Hive metastore）の導入
1500以上のアナリスト（最大300の同時実行ユーザー）
リクエスト全体のうち90%が1分（60秒）以内に完了する

なぜAmazon Athenaにトライしたのか？

Amazon S3上のEMR HBase
- 運用のしやすさ
  - 長期稼働するEMRクラスタ
  - メンテナンスやアップグレードに多大なエンジニアリング・運用負荷が発生
- 複雑性
  - HBaseの内部ノードを暗号化するためのKerberos
- 専門性
  - HBaseの知識がある人材を見つけるのが困難
- 価格
  - なぜ使ってない分にも払わないといけないのか？
Amazon DynamoDB
- 大規模なパフォーマンスは素晴らしいが、価格が高い
- 25PBを保管するにはストレージコストが高価
- ディザスタリカバリ用にもう一つのリージョンにコピーするとさらに課金発生
- データ抽出に課題：どうやって1日で2500億（20TB）のレコードをロードするのか？
Amazon Redshift
- Redshift + Spectrum：クエリするためには、Redshiftのクラスタを立ち上げる必要がある
Amazon Athena
- インフラのプロビジョニング不要
  - インフラのお世話より、もっとビジネスのコア的なタスクに時間がさけるようになる
- 自動スケーリング
  - ピーク時に追加でビルドする必要がない
- 高可用性、セキュア
  - 内部ノードの暗号化、AWS KMSによる暗号化
- 料金
  - 1TBのデータスキャンに$5

Athenaの価格は非常に魅力的
- 実行したクエリに対してのみ支払う vs クラスタを長期化動作させるコスト
- $5でできること：
  - 平均10MBのデータスキャンでは、100,000クエリ
  - 平均100MBのデータスキャンでは、10,000クエリ
  - 平均1GBのデータスキャンでは、1,000クエリ
FINRAは1パーティションあたり2500億のレコードをロード済みで、合計20TBになっている
- しかし必要なデータを全て抽出するのに、クエリはわずか10MBのデータしかスキャンしていなかった

Amazon Athenaを既存のシステムにどう導入したか？

FINRAはHive Metastoreを使用した自社のデータカタログ（HERD）を保有しており、テーブル定義やスキーマを保存している
HERDは、信頼できる唯一の情報源（Single Source of Truth）としている
Hive metastoreをAthenaに統合することが、アーキテクチャの重要なコンポーネントの一つ
完全なサーバレスインテグレーション vs EMRの倹約なソリューション
Glue CatalogとHERD間にパフォーマンスの差はなかった
- → Athena導入が決定

大規模パフォーマンス検証
- ゴール： Athenaで同時100リクエストを90%の割合で処理できることを証明
  - 各処理時間は1分以内
  - 最大3分のレイテンシ
- テストの流れ
  - 2PBのデータをS3にロード
  - 1時間のテストと30分の100同時リクエストの検証
- オレンジのグラフ
  - 5万以上のクエリを飛ばしたが、観測できた失敗数は17のみ
  - 成功率99.9%
  - → Athenaは負荷がかかっていても信頼性が高い
- クエリのレスポンスタイム
  - 平均17秒
  - 95パーセンタイルで32秒、要件をクリアしている

パフォーマンスチューニングTips
- クエリパフォーマンスは、Amazon S3内のデータがどう整理されているかに強く依存する
- パーティショニング・バケッティング
  - よく使われるクエリのフィルタに沿ってパーティション・バケットを選ぶ
- 高パフォーマンスの列志向ストレージ
  - Apache ORCを使用して、
  - 大きめのstripe sizeでApache ORC fileを使用
    - LanguageManual ORC - Apache Hive
- ファイルサイズ
  - ファイルサイズを最適（256MB~1GB）にし、S3データの反復（roundtrips）を減らす
- “S3 Pre-partitioning”
  - パフォーマンス改善のため、Amazon S3チームと共同
運用の準備
- ワークロードをWorkgroupで分割
  - データやログをアプリケーションごとに分離する
- 一時データに対してのみGlue Catalogを活用
  - 保持期間を定めて削除する
- CloudWatchでモニタリング
  - クエリに関するメトリクス、カスタムダッシュボード、リアルタイム通知
- アプリケーションの特定の箇所のモニタリング（Nagios）
  - クエリのキュー時間、実行時間、計画時間などをモニタリング
- JDBC・ODBCドライバ

今後のAthenaに期待する改善点

Hiveバケッティングにしかサポートしていない
- Hiveを使ってAthenaのデータセットを作成するのが遅い
- → Sparkで作成したい
バケット一つに1ファイルの制約を除外したい
- Athenaはファイルの数がバケット数と合っていないテーブルをサポートしていない
- これによってデータが偏る（data skew）
SQLのクエリ計画がない
Presto engineをアップグレードして欲しい
動的フィルタリングがない
PIIやPCI改訂機能がない

将来の展望 - ユニバーサル・データアクセス

Federated queryとAWS Glue
- FINRAのエンタープライズワイドの哲学
  - 適切なアクセスコントロールの元、全ての構造化データにアクセスできるようにする
- 一つのSQLベースのインターフェイスから、複数のストレージ（Amazon S3やAmazon RDS）へアクセス
- 中央集権化されたポリシーの元、テーブル、カラム、行単位でのアクセスコントロール
- 複数のストレージプラットフォームをまたいで、フィルタリングや結合